Model driven architecture (MDA) is an approach to system development advocated by the Object Management Group (OMG). The approach starts by describing the system's specifications using a platform independent model (PIM). A PIM is usually specified in a language that is based on the Meta Object Facility (MOF), a standard by the OMG for describing modeling languages. A prominent example of such languages is the Unified Modeling Language (UML), which is well adopted by the software engineering community. Alternatives to UML also exist and are collectively referred to as Domain Specific Modeling Languages (DSML) (Magyari, E. et. al., “UDM: An Infrastructure for Implementing Domain-Specific Modeling Languages,” 3rd OOPSLA. Workshop on Domain-Specific Modeling, OOPSLA '03), as they are more specialized and target certain modeling domains. Once a system has been specified using a PIM, a platform is then chosen to enable the realization of the system using specific implementation technologies, producing what is referred to as a platform specific model (PSM).
In spite of the potential benefits of MDA including reduced development time for new applications, improved application quality, quicker adoption of new technologies into existing application and increased return on technology investment, the adoption of MDA has not picked up to its full potential yet. One reason for this is the complexity problems inherent in today's MDA tools. These tools usually appeal to the MDA savvy but fall short of meeting the expectations of the mainstream practitioners who are competent with their technologies but not necessarily with MDA. Another reason is the limited support available to the user beyond authoring their models. For instance, features that help the user inspect the quality of their models are lacking in many major MDA tools.
As system models get larger and more complex, the task of inspecting their quality becomes much harder. It is now well understood that a problem detected early on in the system development life cycle is much cheaper to tackle than one discovered later on. Hence, technologies that facilitate inspecting models for quality purposes can certainly play a big role in enhancing the value of MDA. Examples of these technologies include architectural discovery (Booch, G., Handbook of Software Architecture, at www.booch.com/architecture/), anti-pattern detection (Brown, W. et al., Antipatterns: Refactoring Software, Architectures, and Projects in Crisis, John Wiley & Sons, 1998) and consistency analysis (Engels, G. et al., “Consistent Interaction of Software Components,” in Proceedings of Integrated Design and Process Technology, 2002). Equally important are those technologies that assure the quality of the process of going from PIM to PSM. Examples here include impact analysis (Briand, L. et al., “Automated Impact Analysis of UML Models, Journal of Systems and Software, 79(3):339-352, March 2006).
One way to analyze the quality of user models is to look for instances of predefined patterns. Patterns are recurring modeling structures that are either desirable or undesirable (see Brown above). Desirable patterns represent elements of reuse at a higher level of abstraction. Therefore, trying to understand a model by its usage of patterns helps by raising the level of abstraction. Conformance to desirable patterns is expected to boost the quality of models by expediting modeling of maintainable and robust designs. On the other hand, the early identification of undesired patterns, or anti-patterns, protects against making common and expensive design mistakes. It is also a first step towards the mitigation of existing design problems.
Support of patterns has started to show up in some major modeling tools like RSA (IBM Rational Software Architect, at www-128.ibm.com/developerworks/rational/products/rsa/). One common requirement is the definition of a formalism that is used to specify patterns for tool consumption. The state of the art in this area is far yet from converging on a standard for pattern specification.
Pattern specification is a common denominator to most work in applied pattern research. Various approaches have been proposed for pattern specification (Baroni, A. et al., “Design Patterns Formalization”, Ecole Notionale Superieure des Techniques Industrielles, Research Report 03/3/INFO, 2003 and Technical Report 2002). One category of approaches, that Applicant's work also belongs to, uses meta-modeling techniques. The work presented in Guennee, A. et al., “Precise Modeling of Design Patterns,” Proceedings of UML 2000, Vol. 1939 of LNCS, pp. 482-496, Springer Verlag 2000 and Mark, J. “Precise Modeling of Design Patterns in UML,” in Proceedings of the 26th International Conference on Software Engineering, 2004, proposes specifying a pattern as a UML 1.5 meta-collaboration with pattern roles typed with M1 classes stereotyped <<meta>> and named after meta-classes. This obviously prevents writing constraints for such roles as their type information is not available at level M1. Also a new dependency is introduced to describe role bindings as roles are not typed with real meta-classes.
The work in Kim, D., “A UML-Based Metamodeling Language to Specify Design Patterns”, in Proceedings of WiSME, UML Conference, October 2003, introduces the RBML language, which suggests specifying UML patterns as specialized meta-models that characterize M1 models. Pattern roles get their base types by subclassing meta-classes from the UML meta-model. One problem with specifying a pattern as a meta-model is a lack of a context to the specification. This deprives the specification from OO (object oriented) complexity management features like inheritance and composition. It also forces role binding to be done through mapping, which is not as convenient as the present invention solution.
Restated, Applicant finds that use of domain model data (model objects) instead of meta-data (as in the present invention) to describe a pattern limits the expression of the pattern to the semantics of the domain model. This poses a problem if the domain does not have sufficient semantics to completely specify a pattern. Also, this complicates building domain-independent tools that read and process pattern definitions for the purposes of application or detection.
Another proposal is found in Maplesden, D. et al., “Design Pattern Modelling and Instantiation using DPML,” in Proceedings of Tools Pacific 2002, p. 18-21, Sydney, Australia, February 2002, where the DPML language is used to visually specify patterns as a collection of participants, dimensions (multiplicities), relationships and constraints. One drawback is the non-standard notation adopted by the language. Another problem is the restriction of the participants and relationships to predefined types from the UML domain, which limits the scope of the patterns definable by the language. Also, there is no mention of complexity management features.
Another approach (Albin-Amiot, H. and Y. G. Gueheneue, “Metamodeling Design Patterns: Application to Pattern Detection and Code Synthesis”, in Proceedings of the ECOOP 2001 Workshop on Adaptive Object-Models and MetaModeling Techniques, 2001) provides a meta-model to specify patterns. This meta-model is first specialized with pattern related concepts before being instantiated to produce an abstract model (pattern specification) which is either instantiated to create a concrete model (pattern instance) or parameterized to use in pattern detection. One major problem with this approach is using non-standard meta-models. Concepts from a target language like UML are added to the pattern meta-model and defined to subclass pattern related meta-classes which implement functionality needed for pattern application and detection. Enough concepts to specify the Gof patterns are defined.
As mentioned above, patterns are recurring design solutions that have been refined over the years by many practitioners to address common design problems. Software development is a typical domain for applying design patterns and the GoF patterns are not but classic examples of these. Patterns are often informally described in the literature for the purpose of education. However, for tools to work with patterns, they need to be formally specified in a machine consumable format.
The previous art in the area of formal pattern specification is rich with various approaches. Some of these approaches leverage known standards like UML, while others come up with new ways to formalize patterns. For example, the current official proposal to represent patterns in UML is to use a parameterized collaboration. The general structure of the pattern is described in terms of classifier roles and association roles that connect them. Every classifier role has an associated base that is defined as a template parameter and is bound to an actual classifier in a given context (so called instance of a pattern). However, modeling patterns as a parameterized collaboration has severe limitations that were identified in Sunye, G. et al., “Design pattern application in UML”, in ECOOP 2000 Proceedings, (E. Bertino, editor) number 1850, pp. 44-62, Lecture Notes in Computer Science, Springer Verlag, June 2000. For example, while pattern roles can have a multiplicity that is greater than one, only one element is allowed to be bound to every template parameter. Another limitation is that types of connectors unlike types of roles cannot be specified as template parameters and are assumed to be deducted automatically. One more limitation is that not every meta-class from UML is allowed to be used as a template parameter, limiting the ability to use these meta-classes as pattern roles.
Other approaches to patter specification also exist. One category of approaches to pattern specification adopted a mathematical notation by defining special kinds of calculus or formulae. Examples of these approaches include LePUS (Eden, H. H. et al., “Le-PUS—A declarative pattern specification language,” Technical Report 326/98, Department of Computer Science, Tel Aviv University, 1998) and Toufik (Toufikl, T. and D. Ngo, “Formal Specification of Design Patterns—A Balanced Approach,” in Journal of Object Technology, 2(4)127-140, July-August 2003). While some of them focused on structural aspects of patterns, others tried to also incorporate behavioral aspects by adding temporal and state-based logic in their formalisms. One major problem with these approaches is the complexity of the notation, which is a major barrier to adoption by average users. Another category of approaches used special non-standard semantics or graphical notations to describe patterns. Examples of these approaches are described by A. Baroni above. Again, these approaches require a steep learning curve due to deviating from standard notations. Another important category of approaches adopted a meta-modeling approach to pattern specification. An example of this approach is the work in France et al. (France, R. B. et al., “A UML-Based Pattern Specification Technique”, IEEE Transactions on Software Engineering, 30(3)193-206, March 2004). Pattern roles are defined as specializations of meta-classes in the target meta-model. Associations between pattern meta-classes refine some of the associations between the corresponding base meta-classes. Pattern well-formedness rules are expressed with constraints associated with the new meta-classes and behavioral constraints are specified with meta-level behavioral diagrams. One main problem with this approach is a lack of context that binds the new meta-classes together to form a pattern definition, except for being owned by the same meta-model, which limits the reusability of pattern specifications.
Fortunately, the concepts of pattern specification apply not only to UML models but also to other domain specific models and in fact to any data whose structure can be described by a meta-model or a schema. In Eclipse, the EMF framework is used to model structured data by means of specifying an Encore model (basically a UML class diagram) of the entities involved along with their relationships. However, what is needed is a more generic approach to pattern specification; one that leverages and extends the features of EMF to provide a way to manage the complexities and enhance the reusability of pattern specifications.